home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 84 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.1 KB
  1. From: chase@centerline.com (David Chase)
  2. Message-ID: <4dumo5$bav@wcap.centerline.com>
  3. X-Original-Date: 22 Jan 1996 00:45:57 GMT
  4. Path: in1.uu.net!bounce-back
  5. Date: 22 Jan 96 06:01:26 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Throwing an exception from within a si
  9. Organization: CenterLine Software
  10. References: <4doh5o$k04@wcap.centerline.com> <4dos4l$ra9@engnews1.Eng.Sun.COM>
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMQMoROEDnX0m9pzZAQFeHQF+JjIXTw6aCPds2dKE7wRnNSzl0LsYsb4Y
  13.     wAtqeE0UKbxKHXMCFMxnHVpzsQyzo38U
  14.     =UjIq
  15.  
  16. In article <4dos4l$ra9@engnews1.Eng.Sun.COM>,
  17. Steve Clamage <clamage@Eng.Sun.COM> wrote:
  18. >In article k04@wcap.centerline.com, chase@centerline.com (David Chase) writes:
  19.  
  20. >I'm more than willing to assume your implementation technique has merit.
  21. >Yet didn't you say you were not able to get it approved? So what
  22. >is a C++ implementor to do if the only reasonable implementation
  23. >technique violates the platform ABI?
  24.  
  25. Use of techniques not mandated by the ABI does not necessarily
  26. "violate" the ABI.  For instance, Sun's current C++ product uses
  27. PC-ranges, yet these are not discussed in the ABI.  Note that the C++
  28. subroutines interoperate with ABI-conforming subroutines.  Placing
  29. something like that in the ABI merely helps reduce the chance that
  30. each and every language and vendor will do something different and
  31. non-interoperable.  The actual reasons why it didn't make it in had a
  32. lot less to do with technology, and more to do with intercompany
  33. politics (and I must admit that I did not explain myself well at the
  34. time).
  35.  
  36. >I want to say again that a criterion for a feature in the standard is not
  37. >whether you can somehow implement it on some systems. The criterion is more
  38. >like whether you can implement it with appropriate efficiency on all
  39. >systems and not adversely affect programs that don't use the feature.
  40. >If a feature does not meet this criterion, it has to be widely beneficial
  41. >to justify its inclusion.
  42.  
  43. Well, most programs I've seen (Sparc, 386, 68K, VAX) used pretty
  44. simple calling sequences, even in the presence of some scheduling, and
  45. those programs aren't adversely affected by this.  It's efficient on
  46. all reasonable systems (I haven't figured out how it would work on a
  47. B1700, for example), and I've had my ear bent talking to people (at
  48. Sun) doing video about how brain-dead they think it is to not have
  49. asynchronous exceptions.  Furthermore, I fully expect that people will
  50. do stupid stuff in signal handlers, no matter what the standard says.
  51. I realize that there are difficulties (how much of the constructor has
  52. completed?) but they aren't related to maintaining consistent
  53. activation records.
  54.  
  55. Really, this is slightly pointless -- I had this argument with other
  56. people years ago, and I know that it will have no effect on the
  57. language.  However, it is simply not the case that it is difficult to
  58. maintain consistent activation records in the presence of asynchronous
  59. exceptions.
  60.  
  61. speaking for myself,
  62.  
  63. David Chase
  64. ---
  65. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  66.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  67.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  68.